1. Field of the Invention
The present invention relates generally communication interface for communication devices. More particularly, the present invention relates to using Universal Serial Bus (USB) by communication devices having custom features support.
2. Background Art
USB is a serial bus standard for a device interface. USB was originally designed for computers, but its popularity has prompted its commonplace use with video game consoles, PDAs, portable DVDs and media players, cell phones, and even devices such as televisions, home stereo equipment and portable memory devices.
Today, an industry specification, titled “USB Class Definitions for Communication Devices,” Version 1.1, dated Jan. 19, 1999, defines an architecture that is capable of supporting any communication device, which is hereby incorporated by reference in its entirety. As explained therein, there are three classes that make up the definition for communication devices: (1) Communication Device Class, (2) Communication Interface Class, and (3) Data Interface Class. The Communication Device Class is a device level definition and is used by the host to properly identify a communication device that may present several different types of interfaces. The Communication Interface Class defines a general-purpose mechanism that can be used to enable all types of communication services on USB. The Data Interface Class defines a general-purpose mechanism to enable bulk or isochronous transfer on the USB when the data does not meet the requirements for any other class.
A communication device has three basic responsibilities: (1) Device management, (2) Operational management, and (3) Data transmission. The device will use the Communication Class interface to perform device management and optionally for call management. The data streams are defined in terms of the USB class of data that is being transmitted. If there is no appropriate USB class, then designers can use the Data Class defined in the USB specification to model the data streams. Device management refers to the requests and notifications that control and configure the operational state of the device, as well as notify the host of events occurring on the device. Call management refers to a process that is responsible for the setting up and tearing down of calls. This same process also controls the operational parameters of the call. The term “call,” and therefore “call management,” describes processes that refer to a higher level of call control than those processes responsible for the physical connection. Data transmission is accomplished using interfaces in addition to the Communication Class interface. These interfaces can use any defined USB class or can be vendor-specific.
The Communication Class interface is a management interface and is required of all communication devices. This interface is used for device management and, optionally, call management. Device management includes the requests that manage the operational state of the device, the device responses, and event notifications. Call management includes the requests for setting up and tearing down calls, and the managing of their operational parameters. The Communication Class defines a Communication Class interface consisting of a management element and optionally a notification element. The management element configures and controls the device, and includes endpoint 0. The notification element transports events to the host, and in most cases, includes an interrupt endpoint. Notification elements pass messages via an interrupt or bulk endpoint, using a standardized format. Messages are formatted as a standardized 8-byte header, followed by a variable-length data field. The header identifies the kind of notification, and the interface associated with the notification; it also indicates the length of the variable length portion of the message.
The Data Class interface can be used to transport data whose structure and usage is not defined by any other class, such as audio. The format of the data moving over this interface can be identified using the associated Communication Class interface. The Data Class defines a data interface as an interface with a class type of Data Class. Data transmission on a communication device is not restricted to interfaces using the Data Class. Rather, a data interface is used to transmit and/or receive data that is not defined by any other class.
FIG. 1 illustrates conventional abstract control model 100, including USB host 102 and USB device 104, where USB device 104 understands standard V.25ter (AT) commands. As shown, USB device 104 includes carrier modulation (datapump) 116, and controller 108 that handles the AT commands and relay controls. Conventional abstract control model 100 has host-device interface 101 that includes data class interface 110 and communication class interface 106, which are used by USB device 104 and USB host 102 for communication purposes. USB device 104 can also, at times, make use of class interfaces other than data class interface 110 and communication class interface 106, for example a device could use an Audio Class interface for the audio functions in a speakerphone. Communication class interface 106 may include two pipes, where one is used to implement the management element and the other to implement a notification element. In addition, USB device 104 can use two pipes to implement channels over which to carry unspecified data, typically over data class interface 110. For POTS (Plain Old Telephone Service) line control, abstract control model 100 will either support V.25ter commands embedded in the data stream, or V.25ter commands sent down communication class interface 106. When V.25ter commands are multiplexed in the data stream, the Heatherington Escape Sequence or the TIES method would define the only supported escape sequences.
Further, USB device 104 also includes Data Access Control (DAA) 118 for interfacing with the telephone line. Error correction 114 and data compression 112 are implemented in USB device 104. However, error correction 114 and data compression 112 could be implemented on USB host 102, and not necessarily on USB device 104. Also, V.25ter commands are used to control the POTS line interface. ITU Recommendation V.80 defines one way that USB host 102 can control USB device 104 data stream.
Although USB Class Definitions for Communication Devices (or USB CDC) provides a universal interface approach to ensure compatibility between communication devices and host devices, USB CDC introduces certain disadvantages and drawbacks. For example, USB CDC does not provide any support for custom features, such as communication of diagnostics information by USB device 104. As a result, in one conventional approach, USB device 104 manufacturers simply replace USB compliant CDC driver in USB host 102 with a USB custom or non-compliant CDC driver in order to accommodate custom features of USB device 104. Of course, such approach will eventually lead to interoperability and portability issues for USB device 104.
In another approach, USB device 104 uses data pipes of data class interface 110 for communication of information relating to custom features, such as diagnostic information, with USB host 102. In such approach, diagnostic information is embedded in the data stream that is passed by the CDC driver on USB host 102 to the host application, wherein the host application detects and retrieves the embedded diagnostic information. However, this approach utilizes the already-limited USB device 104 data bandwidth, and severely affects the data throughput. For example, if a modem device is provided a data bandwidth of 115 Kbps, transmission of the embedded diagnostic information will consume a portion of the data bandwidth, and adversely affects the modem data throughput.
Accordingly, there is a strong need in the art for a CDC compliant solution that can accommodate USB devices with custom features without adversely affecting the data pipes.